HTTP Strict Transport Security (HSTS) is a web security policy mechanism, which helps to protect secure websites against downgrade attacks and cookie hijacking. It enables web servers to request that web clients (e.g., web browsers or other complying user agents) only connect to the web servers using secure connections (e.g., via Hypertext Transport Protocol Secure (HTTPS)), and never via an insecure protocol such as Hypertext Transport Protocol (HTTP). HSTS is an Internet Engineering Task Force (IETF) standards track protocol and is specified in the Request for Comments RFC 6797, “HTTP Strict Transport Security (HSTS)”.
A HSTS policy is enabled on a host via the transmission from the host of a Strict-Transport-Security HTTP response header field over a secure transport (e.g., TLS, or SSL) to client devices (e.g., the user agents of web applications running on the client devices) that access the hostname. The HSTS Policy directs the client devices to communicate with the host only over secure transport and it specifies a policy retention time duration (e.g., a number of seconds, after the reception of the HSTS header filed, during which the client device is to consider the host as an HSTS host (i.e., the client device can communicate with the host only through the secure transport protocol during this period of time)).
RFC 6797 defines that the HSTS Policy may contain an optional directive “includeSubDomains,” which specifies that the HSTS policy also applies to any hosts whose domain names are subdomains of the HSTS host's domain name. Using this conventional approach, a domain administrator, Alice, may enable an HSTS policy on an apex (root) domain (e.g., ‘example.com’) with ‘includeSubDomains’ with the objective of having all the connections to *.example.com (i.e., to any subdomain of “example.com”) established through a secure protocol (e.g., HTTPS). However, this conventional approach has various shortcomings and limitations. In fact, an HSTS host may offer unsecured HTTP-based services on alternate ports or at various subdomains of its HSTS Host domain name In addition, distinct web applications are offered at distinct subdomains of the HSTS Host, such that web clients often interact directly with these subdomain web applications without having necessarily interacted with a web application offered at the HSTS Host's domain name. If the client devices do not connect to the host domain (e.g., ‘example.com’), they never receive an HSTS header for that host domain and never learn that HSTS is to be enabled for the domain as well as for all its subdomains. In this case, the client devices continue to visit the subdomain(s) (e.g., www.example.com) through an unsecure protocol (e.g., HTTP).
In the conventional approaches, in order to ensure that a subdomain (e.g., a frequent subdomain) is also HSTS enabled, the domain administrator is advised to further configure the subdomain to enable HSTS as well. The exemplary subdomain “www.example.com”, or other popular endpoints (such as “api.example.com,” etc.) are also configured to enable an HSTS policy for that subdomain at the server hosting the subdomain, in addition to the host domain (e.g., “example.com” being HSTS enabled). Therefore in these conventional approaches there is a tedious duplicate configuration for enabling a HSTS policy on a domain and its subdomain. One may understand that this approach will have to be repeated for each subdomain for which the domain administrator would like to enable an HSTS policy.